-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GC bug fix for max_collect_interval
computation
#45727
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Kiran! :)
Wait. I think you need to make sure that jl_n_threads is properly
initialized. It's done after GC setup by default.
…On Fri, Jun 17, 2022, 15:39 Sacha Verweij ***@***.***> wrote:
***@***.**** approved this pull request.
Thanks Kiran! :)
—
Reply to this email directly, view it on GitHub
<#45727 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATBN3JQK5DUJWIBO4C3UK4LVPTWCBANCNFSM5ZDMCCEQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Or at least this was the case in 1.7.1
…On Fri, Jun 17, 2022, 16:31 Jan Rous ***@***.***> wrote:
Wait. I think you need to make sure that jl_n_threads is properly
initialized. It's done after GC setup by default.
On Fri, Jun 17, 2022, 15:39 Sacha Verweij ***@***.***>
wrote:
> ***@***.**** approved this pull request.
>
> Thanks Kiran! :)
>
> —
> Reply to this email directly, view it on GitHub
> <#45727 (review)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ATBN3JQK5DUJWIBO4C3UK4LVPTWCBANCNFSM5ZDMCCEQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Not sure exactly when it changed, but GC initialization happens after threads are initialized. |
The |
Currently constrained to `totalmem / ncores / 2` for `_P64` which results in a very short collect interval when you're running with a smaller number of threads on a machine with many cores. Changes this to `totalmem / nthreads / 2` which, for two of our tests, resulted in 40% and 60% runtime reduction (!!) as well as GC time reduction from 46% to 10% and 64% to 11%.
If this PR causes OOMs, something else is broken. @chflood any thoughts? |
32 bit likes to OOM a lot, or more specifically run out of address space so it could be something else. |
|
Trying to run with this backported to 1.8 I get:
I guess cc @kpamnany |
I'll check. Should I open a PR to a particular branch? |
|
* Bug fix for `max_collect_interval` computation (#45727) Currently constrained to `totalmem / ncores / 2` for `_P64` which results in a very short collect interval when you're running with a smaller number of threads on a machine with many cores. Changes this to `totalmem / nthreads / 2` which, for two of our tests, resulted in 40% and 60% runtime reduction (!!) as well as GC time reduction from 46% to 10% and 64% to 11%. * Move GC init after threading init To allow use of `jl_n_threads` in GC initialization.
Currently constrained to `totalmem / ncores / 2` for `_P64` which results in a very short collect interval when you're running with a smaller number of threads on a machine with many cores. Changes this to `totalmem / nthreads / 2` which, for two of our tests, resulted in 40% and 60% runtime reduction (!!) as well as GC time reduction from 46% to 10% and 64% to 11%.
Currently,
max_collect_interval
is constrained tototalmem / ncores / 2
for_P64
which results in a very short collect interval when you're running with a smaller number of threads on a machine with many cores.Change this to
totalmem / nthreads / 2
which, for two of our tests, resulted in 40% and 60% runtime reduction (!!) as well asGC time reduction from 46% to 10% and 64% to 11%.
Spotted by @janrous-rai.